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DESCRIPTION 
PATIENT PATA ACQUISITION ANP CONTROL SYSTEM 

5 Figl^ pf the Invention 

This invention generally pertainsto communicationsbetween medical devices and, more 
specifically, pertains to a method and apparatus for connecting to and coordinating data 
communications of various medical devices having different communication protocols. 

10 BqskgrQun4 of the Invention 

Medical monitoring devices are used extensively in hospitals, clinics, alternative site 
care, i.e., nursing homes, and at home to monitor a variety of medical conditions. These devices 
basically measure a physiologic condition/state/value from a patient and report the data 
representative thereof as an output of the device, typically by displaying the data on a display 

15 of the monitoring device. For example, when a measurement has been completed by a non- 

invasive blood pressure monitor, the systolic, diastolic, and mean blood pressure as well as the 
heart rate are displayed on the monitoring device. Such information could also be recorded 
manually by the patient or a health care provider or possibly stored in the device for future 
display. 

20 Medical treatment/therapeutic devices are also used extensively in health care. These 

devices typically deliver a therapeutic treatment to a patient as part of the medical treatment. 
Examples are infusion pumps (delivering fluids and/or drugs to the patient), and ventilators 
(delivering gas to the patient). Each therapeutic device has a number of settings that can be 
modified. This is typically accomplished by various input peripherals such as buttons, knobs, 

25 key pads, and the like on the therapeutic device. 

With the rapid development of computer technology, such medical devices are now 
mainly microprocessor-based. This technology now allows for the addition of external 
communications features (input/output) on the devices. At first, this communication was geared 
toward technicians to service the device and sometimes use the device to print out tables of data. 

30 Over the last 5 years, however, there has been a move to using this communication feature to 

report the output data measured by a monitor to another location (often a central office) and to 
remotely modify settings on a therapeutic device by communicating the appropriate input 
information. 
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A direct connection between a single device (monitor or therapeutic device) and a 
central station can be readily constructed. However, a problem arises in coordinating data and 
transmissions when multiple monitors and/or therapeutic devices are used simultaneously or 
interchangeably (especially if such devices were not designed to work together or come from 
5 different manufacturers). This is because medical monitoring devices and therapeutic devices 

differ in at least three aspects: 1) their hardware communication protocol, 2) their software 
communication protocol, and 3) their data (input and/or output). 

In a number of industries, this problem is solved by agreeing on a set of standards to 
enable computers and devices to connect with one another and to exchange information with as 
10 little error as possible (i.e., standardized hardware and software communication protocols and 

data formats). Some of the known protocols include, for example, OSI (Open Systems 
lnterconnection)and SNA (Systems Network Architecture). There are a multitude of standards 
affecting different aspects of communication, such as file transfer (XMODEM, ZMODEM), 
handshaking (XON/XOFF), and network transmissions (CSMA/CD). 
15 To date, unfortunately, only a few medical devices have adapted a communication 

standard (e.g., IEEE #P 1 073.1 Medical Information Bus, "MIB"). This recently introduced 
IEEE standard defines a set of definitions to serve as a basis for common communications 
among a variety of medical devices under the Medical Device Data Language (MDDL). 
Unfortunately, this standard was established too late in the game. Therefore, a majority of the 
20 medical devices in use today were not manufactured to meet this standard. As a result, the data 

that is communicated is often non-standardized.differsfrom manufacturer to manufacturer and 
even sometimes differs with various software versions of the same device. In addition, 
configuration data needed to start the communication process is also non-standardized. 

For example, a certain hardware protocol for serial connections (e.g., RS-232, RS- 
25 422/423/449, etc.) may be defined by a number of communication parameters (e.g., baud rate, 

data bits, stop bits and parity). Each of the parameters have a number of settings (e.g., baud rates 
of 300, 600, 1200, 2400, 9600, 19200, 38400, 57600, 115200, etc.) which have not been 
standardized between devices. Devices also have different software communication protocols 
which define various formatting of data, such as if the data is designed for a line printer versus 
30 packetizeddata. The format is generally the structure or appearance of a unit of data. For line 

printers, there are parameters defining end of line characters and formats for the line. In 
packetized data, for example, there are parameters defining formats (packet, data), headers, and 
end of packet information. Again, each of these parameters include a variety of settings which 
are not standard in the industry. That is, none of the settings for the above-noted parameters have 
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been standardized. Therefore, for each device, the setting information for each parameter must 
be determined and configured. This process is tedious and time consuming. It requires a great 
deal of repetition and additional software and consumes more resources such as RAM, CPU 
time, coding,andthe like. To avoid this problem, many choose to restrict their choice of devices 
to the same manufacturer where the parameter settings are hopefully the same. However, this 
does not provide a solution to the problem, since certain manufacturers do not sell all of the 
devices which may be necessary or do not provide a desired device with certain features. 

Consequently, a need arises for providing a way to efficiently connect to these various 
devices, regardless of manufacturer and/or communication protocol parameter settings. 



Brief Summary of the Invention 
The present invention provides a unique method and apparatus for connecting to and 
coordinating data communications of various devices of differing protocols and parameter 
settings, whether standardized or not . In a preferred embodiment, the invention provides a way 

15 to recognize common parameters of a protocol type and separate out only that part of the 

communication that is different between and specific to the various monitors and therapeutic 
devices. The invention efficiently utilizes defined common parameters of a protocol and 
selectively configures the specific parameter settings when required, automatically. 

Specifically, in a preferred embodiment of the invention, a method of communicating 

20 with various medical devices is provided which includes, for each connected device, identifying 

the common parameters for a specific protocol type and automatically configuring settings for 
said specific parameters. The common parameters are substantially standard between various 
devices having the same protocol type. For example, the common parameters for the RS-232 
hardware protocol type are baud rate, data bits, stop bits, and parity. Within each of these 

25 parameters, there are specific settings which vary from device to device (e.g., baud rates of 300, 

600, 1200, 2400, 9600, 19200, 38400, 57600, 11 5200, etc.). The specific settings for each 
connected device are substantially non-standard between various devices. The method also 
contemplates communication with medical devices which comply with industry standards (e.g., 
MIB). 

30 In a preferred embodiment, the specific parameter settings are automatically configured 

for each device by generally polling each connected device, comparing response from the polling 
step to a list of specific responses for each device, and setting the specific parameter settings 
for each device based on the comparison. This can be accomplished by sending a specific request 
string on a port for a device in a list of devices, and if a response to the request string is matched 
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identifying a specific device, configuring settings for the common parameters associated with 
the protocols for the device on the port, otherwise repeat sending request strings for next device 
in the list until a match. Preferably, a proper baud rate setting is set for the device prior to 
sending the request string and the steps are repeated for each port. 

5 In an alternate embodimenUhe specific parameter settings are automaticallyconfigured 

for each device by a) selecting a baud rate setting out of a list of standard baud rate settings, b) 
sending a first request string on a port, and if a first response to the first request string is 
matched, c) configuring settings for the common parameters associated with the protocols for 
a device which correspondsto the first response, otherwise repeat steps a through c for the next 

1 0 baud rate in the list of standard baud rates. If no responses are matched in the previous steps a 

through c, this embodimentmay further include the steps of a) selecting a baud rate setting out 
of the list of standard baud rate settings, b) sending a second request string on a port, and c) if 
a second response to the second request string is matched, configuring settings for the common 
parameters associated with the protocols for a device which correspondsto the second response, 

15 otherwise repeat steps a through c herein for the next baud rate setting in the list of standard 

baud rate settings. Preferably, the steps are repeated for each port. If a port is specifically 
identified for devices communicating under a standard protocol, the settings may be pre- 
configured to that standard to eliminate the necessity for polling. 

The present invention, in a preferred embodiment, also includes a system for 

20 communicating with various medical devices. This system includes, for each connected device, 

a routine for identifying the common parameters for a specific protocol type and a routine for 
automatically configuring settings for said specific parameters. Pre-configured ports set to 
certain industry standards may also be provided. 

The present invention also provides a method and system for monitoring of at least one 

25 physiologic condition of at least one patient by: a) configuring a protocol of communication 

between at least one medical device and a data acquisition unit connected to at least one of the 
devices by identifying the common parameters for a specific protocol type and automatically 
configuring settings for said specific parameters; b) monitoringa patient's physiologic condition 
through at least one connected medical device to provide data representative of the physiologic 

30 condition; and c) communicating the data to the data acquisition unit connected to the device. 

The method may further include the step of storing the data in the data acquisition unit and 
transmittingthe parameterto a remote location. The medical devices could include monitoring 
devices and/or therapeutic devices. If some form of therapeutic devices are used, or medical 
devices which can be adjusted with commands, the method may further include communicating 
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a command to control the medical device through the data acquisition unit. The communication 
may be initiated at a location remote from the data acquisition unit. In this method, the specific 
parameter settings are automatically configured for each device by polling each connected 
device, comparing response from the polling step to a list of specific responses for each device, 
5 and selecting the specific parameter setting for each device based on the comparison. For 

medical devices with standardized communication protocols, step "a" may be eliminated for 
known protocols. 

Brief Description of the Drawings 
10 Figure 1 is a block diagram of various monitors and therapeutic devices connected to 

the data acquisition and control unit of the present invention which may then be remotely 
connected to a central office or care center for reporting and storing data and controlling the 
attached devices. 

Figure 2 is a schematic diagram of the circuitry of the data acquisition and control unit 
15 of the present invention. 

Figure 3 is a software flow diagram of the functions and operation of the main program 
which generates events for data acquisition and control of the present invention. 

Figures 4a, 4b, 4c, 4d, 4e, 4f, 4g, 4h, 4i, and 4j are software flow diagrams of the 
functions and operation of the event system routines: initialization, exit, post, get from queue, 
20 dispatch, event generate, generate state, generate data, generate time, generate button routines 

respectively, of the present invention. 

Figures 5a, 5b, and 5c are software flow diagrams of the functions and operation of the 
device management system initialization,get device, and set device routines, respectively, of the 
present invention. 

25 Figures 6a, 6b, 6c, 6d, and 6e are software flow diagrams of the functions and operation 

of the device communication system initialization, get data, exit, set data, poll routines, 
respectively, of the present invention. 

Figures 7a, 7b, 7c, and 7d are software flow diagrams of the functions and operation 
of the scheduling system initialization, check, add entry, and delete entry routines, respectively, 
30 of the present invention. 

Figures 8a, 8b, 8c, and 8d are software flow diagrams of the functions and operation 
of the data management system initialization, get data, put data, and delete data routines, 
respectively, of the present invention. 
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Figures 9a, 9b, and 9c are software flow diagrams of the functions and operation of the 
display system initialization, write, and display message routines, respectively, of the present 
invention. 

Figures 10a, 10b, and 10c are software flow diagrams of the functions and operation 
5 of the settings management initialization, get, and set routines, respectively, of the present 

invention. 

Figures 11a and lib are software flow diagrams of the functions and operation of the 
input system initialization button and check button routines, respectively, of the present 
invention. 

10 Figures 12a, 12b, and 12c are software flow diagrams of the functions and operation 

of the external communication system initialization, send data, and receive data routines, 
respectively, of the present invention. 

Detailed Disclosure of the Invention 

1 5 Figure 1 is a block diagram of various monitors 50a, 50b, ... 50z and therapeutic devices 

60a, 60b, ... 60z connected to the data acquisition and control unit 10 of the present invention. 
The unit 10 is designed to recognize, understand, and communicate with each of these devices 
and their unique hardware communication protocol, software communication protocol, and data 
requirements (input and/or output). 

20 Initially, in formulating a solution to the communication protocol problem between 

various medical devices, studies were made of several physiologic monitors and therapeutic 
devices available in the Department of Anesthesiology at the University of Florida. The goal 
of this study was to determine similarities and differences between the communication of these 
devices. The studies showed that the low-level hardware to communicate for most of the devices 

25 was the same, and conform to the EI A RS-232 standard (EIA 1988). [EI A Standard RS-232-C 

1981 Electronic Industries Association Engineering Dept. EIA Standard RS-232-C: Interface 
between Data Terminal Equipment and Data Communication Equipment employing Serial 
Binary Data Interchange. Washington DC, 1981 .] However the data sent over this hardware 
connection and the settings and configuration of the connection are different for all monitors and 

30 therapeutic devices. 

The other commonality that was discovered was the information/data sent or received 
over the connection. For example, a blood pressure monitor always sends systolic and diastolic 
blood pressure in mmHg, and a heart rate in beats/min. Based on this information, the present 
invention defined a common data/protocol format which would allow all of the information that 
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comes from the monitor and all the information that goes to a therapeutic device to be in 
compliance. 

Generally, the present invention solved the communication problem by providing a way 
to separate out only that part of the communication that is different between the various monitors 
5 and therapeutic devices, and to use common methods for the rest. Communicating with devices 

generally requires both hardware protocols (input/output ports, serial interface, RS-232, RS-422, 
parallel interface, DIN, SCSI, network interface, etc.) and software/data protocols (output stream 
format for display or printer, character printer format, line printer format, packetized format, 
etc.). Each of these protqcois requires a certain set of parameters to define the protocol. For 
1 0 example, the RS-232 hardware port has the following parameters for communication: baud rate, 

data bits, stop bits, and parity. Each of these parameters, in turn, have specific settings (e.g., 
baud rate = 300, 600, 1200, 2400, 9600, 19200, 38400, 57600, 1 15200, etc.) which are often 
unique to the device since standardized settings have not been established for all medical 
devices. 

1 5 Although data values transmitted are often the same between similar types of devices 

(e.g., non-invasive blood pressure monitors generally transmit the following three data values: 
systolic value, diastolic value, and heart rate), the way that the data is transmitted varies from 
device to device. The way data is transmitted is accomplished by a certain defined protocol for 
communication. For example, the data can be transmitted in line printer format (protocol) or 

20 packetized format (protocol). If the protocol is of the line printer type, the parameters to define 

such type include the following: end of line character, format of the line. For each of these 
parameters, there is a particular setting such as "end of line character" = "carriage return " 

The present invention provides a unique method and apparatus for connecting to and 
coordinating data communications of various devices having different parameter settings. As 

25 used herein, the term "protocol" generally refers to both hardware protocols and software 

protocols used for communication between devices, systems, and the like. The term "parameter" 
refers to a constant in a particular protocol which varies in other protocols of the same type used 
to define the particular protocol. The term "setting" refers to the value assigned to a specific 
parameter. The term "data" refers to the actual information transmitted (medical sensor values, 

30 etc.) as opposed to the settings information. 

Table 1 below shows the relationship between the hardware communication protocol, 
software communication protocol, and data requirements (input and/or output) for 
monitors/therapeutic devices with respect to the parameters and settings. 
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Table 1. Monitors/Therapeutic Devices 




Aspects 


Protocol 


Parameter(settings) 








baud rate (#) 


5 




RS232 


data bits (#) 




Hardware 




stop bits (#) 




Communication 
Protocol 




parity (even, odd, none) 


10 




par-1 (#) 




i 


Other 


par-2 (#) 








par-3 (#) 








par-n (#) 






I inf* Printpr 


EOL (char) 






format (data) 


1 J 


Software 




packet format (type) 




Communication 
Protocol 


Packetized 


header (data length) 






data (# bytes) 








EOP (CRC field) 








systolic BP (#) 






Type 1 - Blood Pressure 


diastolic BP (#) 


25 






heart rate (#) 




Data Type 




Sp02 (#) 




Type 2 - Infusion Pump 


par-1 (#) (e.g., flow rater) 


30 






par-2 (#)(e.g., concentration) 








par-n (#) (e.g., drug name) 






Type 3 - Other 


par-1 (#) 








par-2 (#) 



For example, in the case of a simple blood pressure monitor that automatically sends 
data each time a new measurement has been taken, the present invention uses common methods 



35 to access the RS-232 hardware, common methods to store, forward, and/or analyze the 

information from the monitor, and uses specific methods to interpret the data stream from the 
monitor. 
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The common identified parametersfor blood pressure monitors are generally the RS-232 
hardware protocol and the data transmitted with the protocol. The RS-232 protocol defines 
voltages and timing sequences needed to communicate data. The same set of parameters are 
used to fully define a connection, namely, baud rate, number of data bits, number of stop bits, 

5 and parity. Settings for these parameters are specific to a particular device, but typically the 

following settings are available: baud rate = 300, 600, 1200, 2400, 9600, 19200, 38400, 57600, 
or 1 15200; data bits = 7 or 8; stop bits = 0 or 1; parity = even, odd, or none. The set of data 
values transmitted with the protocol is also common between the same types of devices. For 
example, a non-invasive blood pressure monitor will usually transmit the following set of data: 

1 0 systolic value, diastolic value, and heart rate. These numeric values can be stored as an ASCII 

string or a binary representation like the IEEE float 754 specification. A timestamp can 
optionally be attached to the data. 

The way this data is transmitted (the protocol) is different between devices (specific to 
the device). Two general formats are used: ASCII string terminated with a carriage return or a 

15 line feed (line printer format); or packetized protocol where binary data packets are sent back 

and forth. When the ASCII string format is used, the data and timestamp are also represented 
as ASCII. When a binary (packetized) format is used, the numeric data and timestamp data can 
be either ASCII or binary. When a packetized format is used, the following data items are 
usually present (their format depends on the device): header information (includes packet length, 

20 checksum, etc.), the data block (containing the numeric data, timestamp, units, etc.), end of 

packet information (usually contains a specific packet termination). Checksums are commonly 
calculated with the 16-bit CCITT checksum. 

From the above-noted example, it can be seen that for almost any blood pressure 
monitor, the common parameters would be the RS-232 parameters of baud rate, number of data 

25 bits, number of stop bits, and parity (the setting for which are specific) and the set of data: 

systolic value, diastolic value, and heart rate (the format for which is specific). The software 
coding for these commonalities can be reused and only the specifics would need additional 
coding. Accordingly, when new blood pressure devices are added, the previously developed code 
for the above- identified common parameters can be re- used which saves time, resources, coding 

30 and the like. 

To implementthe present invention, first, a functional specification of the hardware was 
made. This particular implementation of the invention was designed to 1) communicate with 
several different physiologic monitors or therapeutic devices via a serial connection (RS-232), 
including sending commands to start measuring a parameter and collecting the parameters and 
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waveform data from the device; 2) communicate via modem(or other communication device) 
with a central station at certain (configurable) intervals, including accepting orders to monitor 
certain parameters at certain times from the central station and security -user/device 
identification; 3) display simple instructions to the patient; 4) accept simple input (button 

5 presses) from the patient; S) provide an audio alarm to alert the patient to messages on the 

display or to indicate the next measurement is due; and 6) store data when there is no dial-up 
connection, even when there is a power failure. 

As shown in Figure 2, the preferred embodiment of the data acquisition and control unit 
10 contains the following basic hardware elements: a microprocessor 20 for control (e.g., 386 

10 SZ 40Mhz ISA card part # PC-310-386X, available from E.G. Technology Corp., Livingston, 

NJ, USA); semiconductor-based memory 22 (e.g., 4Mb memory part #MMlX36-70, available 
from E.G. Technology Corp.); a solid-state disk drive 24 for mass storage (e.g., 1.5Mb solid- 
state disk for PC-3 1 0 part #OT-SSD 1 .5MB,available from E.G. Technology Corp.); a backplane 
26 with a plurality of slots (e.g., Backplane ISA 3 slot part #BP-I3 available from E.G. 

1 5 Technology Corp.); a multi-port serial board 28 (e.g., four port serial board 1 6550 UARTS part 

#90 13-S5-4, available from Byte Runner Technologies, Knoxville, TN, USA); and a display 30 
(e.g., LCD backpack part # BPK-420L, available from Scott Edwards Electronics, Sierra Vista, 
AZ, USA). Additional ports, such as these for standardized Medical Information Bus 
communications defined by the Medical Device Data Language (MDDL-IEEE PI 073), or the 

20 like may also be provided. A user interface 40 may include any standard input device(s) such 

as touch screen, push buttons, key board, mouse, and the like. A status light 42 may also be 
included. Power is preferably provided by a power source, not shown, which may be alternating 
or direct current (battery operated) or include battery back-up power. Standard 1 1 5 VAC power 
may be utilized with a power transformer 44 to provide the necessary DC output for the 

25 circuitry. A standard bus configuration 46 transmitsdata between the microprocessor, memory, 

ports and modem. If external communication is desired, a modem 48 or similar external 
communicationdevice (telephone, microwave relay, satellite link, cable, network, and the like), 
may be provided. 

The unit 10 may be directly or remotely connected to a central office 70 or care center 
30 for reporting and storing data and controlling the attached devices. In a preferred embodiment, 

the data acquisition and control unit 10 of the present invention preferably utilizes a single board 
computer capable of running the MS-DOS operating system. It is envisioned that the remote unit 
may be used in a variety of situations where remote monitoring may become necessary, such as 
on vessels out at sea, rural villages and towns, and the like. The data may be transmitted (via 
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modem, satellite, radio wave, wiring, infra-red, or other communication means) to a "central 
station" or other location as desired, such as a doctor's office, nurse's station, third-party 
monitoring station, alternative sites, base stations, port/naval stations (from a ship), and the like. 
The term "remote" as used herein does not necessarily mean "far removed." The unit 10 may 
5 be directly attached (hard-wired) to its "central office" in the same room or building. 

Furthermore, the functions of the "central office" (such as visual displays, data recording, 
control, etc.) may be incorporated into a single system in conjunction with the unit 10 if desired. 

The method of the present invention in a preferred embodiment can be implemented in 

10 "C" programming language with the program running on an MS-DOS operating system. The 

method of the present invention is described with reference to the fol lowing description and flow 
diagrams of Figures 3-12. 

The main loop of the software (Fig. 3) is operating an event system in which each task 
is given a finite amount of processor time. The main program 300 starts with an INITIALIZE 

1 5 EVENT SYSTEM 302 (the details of which are shown in Figure 4a, evenlnit function 400). The 

event system contains an event queue that allows prioritization and execution of events. The 
program checks for a QUIT EVENT 304 and if not posted proceeds to GENERATE EVENTS 
306 and EXECUTE EVENTS 308. This loop continues until a QUIT EVENT is posted and 
proceeds to DEINITIALIZE EVENT SYSTEM 310 to the end of the program 312. 

20 Several subsystems use the event system: the device, the scheduling system, the data 

management system, the display system, the settings management system, the input system, and 
the external communications system. 

The operation of the event system is shown in the flow diagrams of Figures 4a, 4b, 4c, 
4d, 4e, 4f, 4g, 4h, 4i, and 4j. The event system is initialized at the beginning of the program 

25 (Fig. 4a). The eventlnit function 400 allocates the event queue and readies the event system for 

use. Deinitializationis done at the end of the program with the eventExit function 410 (Fig. 4b). 
The program can call the eventPost function 420 (Fig. 4c) to add an event to the queue at a 
certain priority. The eventGet function 430 (Fig. 4d) is called by the programs main loop to 
retrieve the next event and, when one is available, the eventDispatch function 440 (Fig. 4e) is 

30 called to execute the event. When no events are available, the eventGenerate function 450 (Fig. 

4f) is called to generate any events that need to be generated, for example: GENERATE STATE 
EVENT 460 (Fig. 4g) which checks for message time out and whether the next scheduled event 
is due; GENERATE DATA EVENT 470 (Fig. 4h) which polls the DevSOMs; GENERATE 
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TIME EVENT 480 (Fig. 4i) which providesa timer function; or GENERATE BUTTON EVENT 
490 (Fig. 4j) which checks whether a button was pushed. 

The device management system is shown in Figures 5a through 5c. The device manager 
maintains the connection with the physiologic monitors and therapeutic devices. The 
5 deviceManagerlnit function 500 (Fig. 5a) is called at the start of the program. The present 

invention defines a Device Specific Operation Module (DevSOM) for each device containing 
the methods that are specific to a monitor or therapeutic device and saves the various DevSOMs 
in a database. This database may be updated manually or automatically by remote 
communication as new devices are developed and/or employed. The deviceManagerlnit function 
1 0 500 makes a catalog of available device DevSOMs. 

Of course, each non-standard device must be identified and configured. The present 
invention provides a unique automatic configuration process as described herein. The preferred 
method is to have a database that contains: the name of the DevSOM, the name of the device, 
the baud rate, a request string, a response string. This database is used to identify which devices 
1 5 are attached to which ports as follows: For the first device in the database, the proper baud rate 

is set on the first port, and the first request string is sent. A fixed time is used to wait for a 
response. If the response matches the response string for the first device, the device is detected. 
If the device was not detected, the information from the second device in the database is used, 
until there are no more devices. This process is repeated for all the ports. Communication with 
20 devices connected to standardized ports (e.g., MIB/MDDL) may be pre-configured. 

In an alternate embodiment of automatic configuration, the invention defines a database 
of DevSOMs that contains: the name of the DevSOM, the name of the device, response to 
string 1 at several standard baud rates, response to string2 at several standard baud rates. This 
database is used to identify which devices are attached to which ports as follows: The first baud 
25 rate is selected on the first port. The first string (stringl ) is sent to the port. A fixed time is used 

to wait for a response. If the response is recognized the device is detected. If the device is not 
detected, a second baud rate with stringl is used. The process continues until all baud rates for 
stringl are tried. Then the process continues with string2. This process is repeated on the 
remainder of any non-standard ports. In order to rule out duplicates, it is ensured that there are 
30 no duplicate responses in the database. Other methods of polling the various ports to 

automatically configure the communications between the devices and the unit 10 utilizing the 
DevSOM database are contemplated herein. 

In the preferred embodimentthe DevSOMs for every device are compiled into the main 
program. As an alternative, the DevSOMs could be dynamically loaded from memory (or like 
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storage medium). When automatic configuration of DevSOMs is enabled 502, the automatic 
configuration procedure, described above, is used. If automatic configuration is not enabled, a 
configuration file is read 502. Running the automatic configuration identifies which device is 
connected to which port and which method/protocol of a specific DevSOM is to be used. For 

5 each device the devsomlnit function contained in the DevSOM for the device is called 504. As 

previously stated, only the specific methods/protocols are included in the DevSOM since 
commonalities have already been defined by the present invention. 

The devsomlnit function 600 of the DevSOM will do whatever initialization is needed 
for a specific device and will return a DevSOM data block (See Table 2) with additional 

1 0 information about the device. The DevSOM data block preferably contains the name of the 

device, the number of parameters that can be measured including their names, the number of 
parameters that can be modified including their names, and pointers to DevSOM functions. 



15 



20 



25 



30 



35 



Table 2. DevSOM Data Block 



Name of the device 



Number of measured parameters 



Name list of measured parameters 



Number of settable parameters 



Name list of settable parameters 



devsomExit function pointer 



devsomGetData function pointer 



devsomSetData function pointer 



devsomPoll function pointer 



Currently, as shown in Figures 6a through 6e, the following DevSOM functions are 
preferably implemented in a DevSOM: devsomlnit 600 (Fig. 6a) - initializes the DevSOM and 
returns a DevSOM data block; devsomExit 620 (Fig. 6c> deinitializes the DevSOM; 
devsomGetPata 610 (Fig. 6b) - retrieves the latest value of a parameter, including timestamp and 
units; devsomSetPata 630 (Fig. 6d) - sets a device parameter; devsomPoll 640 (Fig. 6d) - give 
the DevSOM some CPU time to do housekeeping which some devices require. 

The Device Manager (Fig. 5a - 5c) is used to set and get data to/from a device. The 
deviceManagerGet function 510 (Fig. 5b) is called whenever data needs to be retrieved from a 
device. In this function, a specific device (as indicated by its port number) can be indicated, or 
the Device Manager can search the list of connected devices for a device that provides the 
indicated parameter. 
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To change data in a therapeutic device the deviceManagerSet function 520 (Fig. 5c) is 
used. It is required for this function to indicate which parameter on which device needs to be 
set. 

Turning now to the Scheduling System (SS) of Figures 7a through 7d, this system is 
5 responsible for maintaining the schedule at which measurements are to be taken or at which 

treatment is to be modified. The schedule is maintained in a table which may be stored in 
memory such as stored on a Storage Medium (SM), e.g., solid state disk drive 24. Each table 
entry contains the starting date and time of the event, the interval at which the event is to take 
place, the ending date and time of the event. In addition, a daily start and stop time can be 
10 indicated if, for example, measurements are only to be taken between 8:00 a.m. and 8:00 p.m. 

When an event is due the event will be posted to the Event System, which implement 
its execution. 

The SS is initialized at the start of the program with the schedulelnit function 700 (Fig. 
7a). This function reads the schedule table from the SM. The function scheduleCheck 710 (F ig. 
1 5 7b) is called often (as often as CPU power allows). This function checks the schedule and posts 

any events that are due. Entries can be added to the schedule table with the scheduleAddEntry 
function 720 (Fig. 7c), and can be deleted from the table with the scheduleDeleteEntry function 
730 (Fig. 7d). 

Turning now to the Data Management System (DMS) of Figures 8a through 8d, the 
20 DMS is responsible for storing and retrieving measured data. When data has been measured, 

it is passed to the DMS where it is stored in temporary storage (TS), e.g., solid state disk or 
RAM. Data can be retrieved from the TS and passed on to other systems via the External 
Communication System (FIG. 1 2a - 1 2c). After data has been forwarded to another system, data 
can be deleted from the TS. The TS retains its data even when the power goes out. 
25 The DMS is initialized at the beginning of the program with the datalnit function 800 

(Fig. 8a). This function reads the TS and creates a catalog of it in memory. The dataPutData 
function 820 (Fig. 8c) adds data to the TS and the dataDeleteData 830 (Fig. 8d) is used to delete 
data from the TS. The dataGetData function 810 (Fig. 8b) is used to retrieve the whole data 
table, or just a portion of it (for example filtered by parameter identification). 
30 The display system (Fig. 9a - 9c) is used to display short messages to the user. The 

displaying function 900 (Fig. 9a) initializes the Display System. Messages can either be written 
directly to the display with the displayWrite function 910 (Fig. 9b), or predefined messages can 
be displayed with the displayMessage function 920 (Fig. 9c). The displayMessage function 920 
displays the message in the configured language and can be tailored to a specific device. 
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Settings Management is shown in Figures 10a through 10c. Settings can be stored and 
are retained even when power goes out. Settings include, but are not limited to: the number of 
patients using the device, their names, the phone number used by the external communication 
system, configured language, and the like. The settingslnit function 1000 (Fig. 10a) initializes 
5 the Settings Management system. Settings can be read with the settingsGet function 1010 (Fig. 

10b) and set with the settingsSet function 1020 (Fig. 10c). 

The Input System (Fig. 1 la - lib) provides means for the user to interact with the 
system. Currently, three simple input buttons are provided in the preferred embodiment. The 
labels for the buttons can be changed depending on the message on the display system. The 
1 0 activation of a button is checked with the buttonCheck function 1110 (Fig. 1 1 b) which is called 

from the eventGenerate function 1100 (Fig. 1 la). 

The External Communication System (Fig. 12a - 12c) provides the means for 
transporting the data that was stored in the unit 10 to another system, or for another system to 
provide settings to the unit 10 or one of its attached devices. The External Communication 
1 5 System can communicate over standard RS-232 serial ports, modems, network adapters, or the 

like. Multiple connections can be maintained at the same time. 

The External Communication System is initialized with the ecslnit function 1200 (Fig. 
12a). The ecsSendData function 1210 (Fig. 12b) can be used to send data on the communication 
line and the ecsReceiveData function 1220 (Fig. 12c) can be used to receive data from the 
20 communication line. 

Alarms can be provided for failures in the system, including an autoconfiguration 

failure. 

Following are examples which illustrate procedures for practicing the invention. These 
examples should not be construed as limiting. 

25 

Example l - Blood Pressure Monitor 

The deviceManagerlnit function is called at the start of the program. The invention 
includes in its database a Device Specific Operation Module (DevSOM) for the particular device 
containing the methods that are specific to it. In this example, the invention defined the 
30 DevSOM for the "Critikon Dinamap 1 846SX non-invasive blood pressure monitor with Sp02 

module" by separating out the common parameters (RS-232 hardware, line printer protocol, and 
data set) and identifying and setting the specific protocols used in this device. The device is 
automatically configured according to the methods of the present invention. 
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In this particular example, the device utilized the common RS-232 hardware protocol. 
The parameters and settings for the RS-232 were defined as follows: baud rate = 600, data bits 
= 8, stop bits = 1 and parity = even. The devsomlnit function opens the RS-232 port with the 
above settings. This function will return a DevSOM data block with additional information 

5 about the device. The devsomExit function is used to close the RS-232 port. 

The data for such a monitor includes the following: systolic blood pressure (BPsys), 
diastolic blood pressure (BPdia), heart rate (HR), and Sp02. The communication protocol was 
defined as "line printer" for which the common parameters of end of line (EOL) character and 
data formats were determined to have the following specific settings: EOL = carriage return; 

10 BPsys data format = 3 ASCII characters starting at position 23 if line begins with BBC; BPdia 

data format = 3 ASCII characters starting at position 27 if line begins with BBC; HR data 
format = 3 ASCII characters starting at position 20 if line begins with BBC; Sp02 data format 
= 3 ASCII characters starting at position 1 1 if line begins with EAA. In operation, the 
devsomPott function sends request data string 1 (B*C<carriage return>) every even second and 

1 5 sends request data string2 (E* A<carriagereturn>) every odd second. The data is read from the 

device. If EOL is received, the data is parsed according to the defined data formats and stored 
in an internal data table ready to be retrieved by devsomGetData function. The devsomSetData 
function is not used with this device. 



20 Example 2 - Multi-parameter MonitQr 

The deviceManagerlnit function is called at the start of the program. The invention 
includes in its database a Device Specific Operation Module (DevSOM) for the particular device 
containing the methods that are specific to it. In this example, the invention defined the 
DevSOM for the "Propaq Encore multi-parameter monitor" by separating out the common 

25 parameters (hardware = RS-232, software = packetized format, and data set) and identifying and 

setting the specific parameters used in this device. The device is automatically configured 
according to the methods of the present invention. 

In this particular example, the device utilized the common RS-232 hardware protocol. 
The parameters and settings for the RS-232 were defined as follows: baud rate = 1 9200, data bits 

30 = 8, stop bits = 1 and parity = even. The devsomlnit function opens the RS-232 port with the 

above settings. This function will return a DevSOM data block with additional information 
about the device. The devsomExit function is used to close the RS-232 port. 

The data for such a monitor includes the following: systolic blood pressure (Bpsys), 
diastolic blood pressure (Bpdia), heart rate (HR), Sp02 and more parameters depending on 
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connected inputs. The communication protocol was defined as "packet format" for which the 
common parameters of packet header (data length 2 bytes), data section (packet type, n bytes), 
end of packet information (CRC field - 2 bytes) were determined to have the specific settings 
as noted in parentheses. 

5 In operation, the devsomPoll function sends a sensor request packet (packet type 1 7) for 

each parameter to be monitored every second. It then sends an autolink packet (packet type 5) 
to inform the monitor that the connection is still ongoing. It also parses the response packets and 
fills out an internal data table. The devsomSetData function is not used with this device. 



10 Example 3 - Infusion Pump 

The deviceManagerlnit function is called at the start of the program. The invention 
includes in its database a Device Specific Operation Module (DevSOM) for the particular device 
containing the methods that are specific to it. In this example, the invention defined the 
DevSOM for the "Alaris P6000 syringe pump" by separating out the common parameters 

1 5 (hardware = RS-232, software = packetized format, and data set), and identifying and setting the 

specific parameters used in this device. The device is automatically configured according to the 
methods of the present invention. 

In this particular example, the device utilizes the common RS-232 hardware protocol. 
The parameters and settings for the RS-232 were defined as follows: baud rate = 9600 baud, 

20 data bits = 8, stop bits = 1 , and parity = none. The devsomlnit function opens the RS-232 port 

with the above settings. This function will return a DevSOM data block with additional 
information about the device. The devsomExii function is used to close the RS-232 port. 

The data for such a treatment device that can be retrieved include: total infused volume, 
selected drug, etc. The data for this device that can be set include: infusion rate, upper limit of 

25 the infused volume, etc. 

The communication protocol was defined as "packet format"* for which the common 
parameters of packet header (data length 3 bytes), data section (data length 2 bytes, data n bytes), 
end of packet information (CRC field 2 bytes) were determined to have the specific settings as 
noted in parentheses. 

30 In operation, the devSOMPoll function sends an infused volume request packet ("0,VI 

?") to request an update on the total infused volume, and a selected drug request packet ( w 0,DR 
?") to request an update on the selected drug. The requested data is then sent back from the 
device, is parsed, and stored in an internal data table. The devSOMSetData function can be used 



BNSDOCID; <WO O025496A2J, > 



WO 00/25496 



PCT/US99/25160 



18 

to update the infusion rate. The devSOMSetData function will send the set rate packet 
("(^RS^xxx.xml/h"), which will cause the infusion rate on the pump to change as instructed. 

It should be understood that the examples and embodiments described herein are for 
5 illustrative purposes only and that various modifications or changes in light thereof will be 

suggested to persons skilled in the art and are to be included within the spirit and purview of this 
application and the scope of the appended claims. 
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Claim? 



1 1 . A method of communicating with various devices comprising identifying specific 

2 protocols for each connected device and automatically configuring settings for said common 

3 parameters associated with each of said protocols. 

1 2. The method of claim 1 wherein said protocols comprise hardware and software 

2 protocols for communication. 

1 3. The method of claim 2 wherein said hardware protocols comprise RS232 type 

2 comprising common parameters of baud rate, data bits, stop bits and parity associated therewith. 

1 4. The method of claim 2 wherein said software protocols comprise 

2 line printer type comprising common parameters of end of line character and 

3 line format, and 

4 packetized data type comprising common parameters of packet format, header, 

5 data format, and end of packet information. 

1 5. The method of claim 2 wherein said protocols further comprise input/output format 

2 for data sets. 

1 6. The method of claim 1 wherein said settings are automatically configured for each 

2 device by 

3 (a) polling each connected device, 

4 (b) comparing response from said polling step to a list of specific responses for 

5 each device, 

6 (c) setting said specific parameter settings for each device based upon said 

7 comparison. 

1 7. The method of claim 1 wherein said settings are automatically configured for each 

2 device by 

3 (a) sending a specific request string on a port for a device from a list of devices 

4 each having unique request and response strings, 

5 (b) receiving a specific response; 
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6 (c) if said response to said request string matches, thereby identifying a device, 

7 configuring settings for said common parameters associated with said specific 

8 protocols for the device on said port, otherwise repeat steps a through c for next 

9 device in said list. 

1 8. The method of claim 7 wherein a proper baud rate is set for said device prior to 

2 sending said request string. 

1 9. The method pf claim 8 wherein said steps are repeated for each port. 

1 1 0. The method of claim 1 wherein said settings are automatically configured for each 

2 device by 

3 (a) selecting a baud rate setting out of a list of standard baud rate settings, 

4 (b) sending a first request string on a port, 

5 (c) if a first response to said first request string is matched, thereby identifying a 

6 device, configuring settings for said common parameters associated with said 

7 specific protocols for the device which corresponds to said first response, 

8 otherwise repeat steps a through c for the next baud rate in said list of standard 

9 baud rates. 

1 11. The method of claim 1 0 further comprising the steps of: 

2 (a) if no responsesare matched in steps a through c of method 10, selecting a baud 

3 rate setting out of said list of standard baud rate settings, 

4 (b) sending a second request string on a port, 

5 (c) if a second response to said second request string is matched, thereby 

6 identifying a device, configuring settings for said common parameters 

7 associated with said specific protocols for the device which corresponds to said 

8 second response, otherwise repeat steps a through c herein for the next baud rate 

9 setting in said list of standard baud rates. 

1 12. The method of claim 10 wherein said steps are repeated for each port. 

1 13. The method of claim 1 1 wherein said steps are repeated for each port. 
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1 14. A system for communicating with various devices comprising: 

2 a routine for identifying specific protocols for each connected device and automatically 

3 configuring settings for said common parameters associated with each of said protocols. 

1 15. The system of claim 1 4 wherein said selection routine performs the following 

2 steps: 

3 (a) polling each connected device, 

4 (b) comparing a response from said polling step to a list of specific responses for 

5 each device to identify a specific protocol for each connected device, 

6 (c) configuring settings for said common parameters associated with said specific 

7 protocol for each device based on said comparison. 

1 16. The system of claim 14 wherein said selection routine performs the following steps: 

2 (a) sending a specific request string for a device in a list of devices on a port, 

3 (b) if a response to said request string is matched, thereby identifying a device, 

4 configuring settings for said common parameters associated with said specific 

5 protocols for said device connected to said port, otherwise repeat steps a and b 

6 for next device in said list. 

1 17. The system of claim 14 wherein said selection routine performs the following steps: 

2 (a) selecting a baud rate setting out of a list of standard baud rate settings; 

3 (b) sending a first request string on a port; 

4 (c) if a first response to said first request string is matched, thereby identifying a 

5 device, configuring settings for said common parameters associated with said 

6 specific protocols for the device which corresponds to said first response, 

7 otherwise repeat steps a through c for the next baud rate in said list of standard 

8 baud rates. 

1 1 8. The computer system of claim 1 7 further comprising the steps of: 

2 (a) if no responses are matched in steps a through c of claim 1 7, selecting a baud 

3 rate out of said list of standard baud rates; 

4 (b) sending a second request string on said port; 

5 (c) if a second response to said second request string is matched, thereby 

6 identifying a device, configuring settings for said common parameters 
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7 associated with said specific protocols of the device which corresponds to said 

8 second response, otherwise repeat steps a through c herein for the next baud rate 

9 in said list of standard baud rates. 

1 1 9. A method for monitoring of at least one physiologic condition of at least one patient 

2 comprising the steps of 

3 (a) configuring a protocol of communication between at least one medical device 

4 and a data acquisition unit connected to at least one of said devices by 

5 identifying specific protocols for each connected device and automatically 

6 configuring settings for said common parameters associated with each of said 

7 protocols; 

8 (b) monitoring a patient's physiologic condition through at least one connected 

9 medical device to provide data representative of said physiologic condition; 

10 (c) communicatingsaiddatato said data acquisition unit connected to said device. 

1 20. The method of claim 1 9, further comprisingthe step of storing said data in said data 

2 acquisition unit and transmitting said parameter to a remote location. 

1 21. The method of claim 19, wherein at least one of said medical devices is a 

2 monitoring device. 

1 22. The method of claim 19, wherein at least one of said medical devices is a 

2 therapeutic device. 

1 23. The method of claim 22, further comprisingthe step of communicating a command 

2 to control said therapeutic device through said data acquisition unit. 

1 24. The method of claim 23, wherein said communicating is initiated at a location 

2 remote from said data acquisition unit. 

1 25. The method of claim 19, wherein said settings are automaticallyconfigured for each 

2 device by 

3 (a) polling each connected device, 
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4 (b) comparing response from said polling step to a list of specific responses for 

5 each device, 

6 (c) setting said specific parameter settings for each device based on said 

7 comparison. 

1 26. A system for monitoring of at least one physiologic condition of at least one patient 

2 comprising: 

3 (a) means for configuring a protocol of communication between at least one 

4 medical device and a data acquisition unit connected to at least one of said 

5 devices by identifying specific protocols for each connected device and 

6 automatically configuring settings for said common parameters associated with 

7 each of said protocols; 

8 (b) means for monitoring a patient's physiologic condition through at least one 

9 connected medical device to provide data representative of said physiologic 

10 condition; 

1 1 (c) means for communicating said data to said data acquisition unit connected to 

12 said device. 

1 27. The system of claim 26, further comprising means for storing said data in said data 

2 acquisition unit and means for transmitting said parameter to a remote location. 

1 28. The system of claim 26, wherein at least one of said medical devices is a monitoring 

2 device. 

1 29. The system of claim 26, wherein at least one of said medical devices is a therapeutic 

2 device. 

1 30. The system of claim 29, further comprising means for communicating a command 

2 to control said therapeutic device through said data acquisition unit. 

1 31. The system of claim 30, wherein said means for communicating initiates the 

2 communication at a location remote from said data acquisition unit. 
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1 32. The system of claim 26, wherein said means for automatically configuring said 

2 specific parameter settings comprises: 

3 (a) means for polling each connected device, 

4 (b) means for comparing response from said polling step to a list of specific 

5 responses for each device; and 

6 (c) means for setting said specific parameter settings for each device based on said 

7 comparison. 

1 33. The system of claim 26 further comprising: 

2 means for connecting standardized medical devices to said data acquisition unit 

3 wherein communication protocols are pre-defined. 
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